Subject: Electronic AP for DLSw Multicast

From: David Bryant/HQ/3Com <[email-masked]>
Date: 19 Sep 96 17:49:59 EDT

Sorry for the delay in responding guys... some long needed
vacation and work crisises kept me away.

Sounds like I'm going to have to put out a new version of 
the document to address some of the (very valid)concerns brought
up.  So please get me your comments on these proposed changes 
by 9/25 and I will get a new verision of the spec out by 9/27 
and will want go AP on it if there are no substantial objections 
by 10/11.

Here's a list of the issues (as I read them) and responses:

1).  What are we asking AP approval on

I'm asking for AP status on the DLSw Multicast proposal only. 
The current plan (as discussed at the AIW)is that we will try 
to gain AP status on DLSw Multicast at AIW 11 (now occurring 
electronically).  Then Paul Brittan will create a new document
containing the DLSw Multicast proposal and other approved DLSw 
changes into a single DLSw Version 1.1 document for CP approval
at AIW 12 (Nov '96).  This latter item is looking less likely 
every day.  And, I have not as of yet received any indication 
from Paul that he will be able to create the DLSw Ver 1.1 spec. 
in the time necessary to receive CP at AIW 12.  

2). Single Tunnel activation with DLSw Multicast 

You guys are right.  I went into the document and changed the 
read port to 2067, but didn't look closely enough at what I was 
doing to realize I need to add clarification text.   It is my 
intent to say that DLSw Multicast nodes should establish a single 
TCP connection on 2067.   This still leaves a potential race 
condition whereby two DLSws bring up connections to 2067 at the 
same time.   In this case, the DLSw with the higher IP address 
must tear down it's connection after the capabilities exchange 
using a new reason code: x'000E' - unnecessary excess connection
terminated 

This shouldn't create a problem when connecting to down-level 
(non-multicast) DLSw's because these types of connections must 
be predefined anyway.  So the DLSw should know to use the RFC 
1795 method.

Clarifying this will take some text in several places in the 
document... so it sounds like I'm sending out a new updated 
version.  Please give me your comments by 9/25, before I bother
to do so.

3). UDP Packet parsing 

Sounds like there's some concern over the text describing how/when
to ignore imbedded control vectors. I put this in because that was 
(and always is) the working assumption in RFC 1795 (and SNA).   
But it was never documented.  It's purpose with respect to this 
document is currently not needed, but might be in the future.   
I figured putting it in now, might help avoid problems or at least 
establish a way to rule on who implemented correctly in the future.   
I advise keeping it in, but am ambivalent.   Since it seems 
to create some level of concern, the easiest thing to do is remove 
it.  I propose to do that unless someone strongly wants it in 
(and let's me know prior to 9/25). 

4). NetBIOS transport chart updates

I'm ok with the suggested updates (basically saying unicast vs.
multicast is an implementation issue based upon whether the sending
node has cached enough information to determine which is necessary).
I'm also ok with simply deleting the statement regarding DATAGRAM 
frames and whether they flow as DATAFRAMEs or DGRMFRAMEs.  This is 
covered in RFC 1795 and need not be covered in the multicast document. 

5). Vendor Specific UDP packet 

Couple issues here.

5.1). Header length

The header length should be at least 7 and could be higher if the 
vendor chooses.  I will add text accordingly

5.2). Message type following OUI

I don't think this is necessary.  I think the easier thing to do 
is to simply strike the statement that AIW standards will 
use an OUI of zeros.   This way we'll leave AIW standard UDP packet 
formats to be defined later.   We also potentially save 3 bytes
on each packet. 

5.3). Clarification text

Sounds like folks want more text clarifying the fields of the
vendor specific UDP packet header.   I'll do this, but it will 
be pretty simply now.  I'll add text that the header length is
always 7 or higher.  I'll remove text regarding AIW standards
using zeros.   Is there anything else anybody feels I should add?

6). Typos etc.

- I found and agree with all but "Single session TCP connections: 
section; first paragraph, first sentence... where's the error?
- "Vendor Specifi Functions over UDP"; second paragraph, first 
sentence... what second paragraph?
- change "set of DLSw" to "set of DLSws"... couldn't find, 
where is this? Found and corrected this under "Unicast UDP 
Datagrams"

7). DLSw Discovery

That's a seperate topic that I'll leave to those with an interest.
I suggest this discussion be moved outside the DLSw-scalability Riglet.

Anything else??? 

Regards, Dave
PS.  Boy will I be glad when this is done!